-
Notifications
You must be signed in to change notification settings - Fork 8.5k
[Response Ops][Reporting] Scheduled Reports - List and Disable API #220922
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Response Ops][Reporting] Scheduled Reports - List and Disable API #220922
Conversation
…:ersin-erdal/kibana into 216308-support-rrule-for-task-scheduling
… src/core/server/integration_tests/ci_checks'
…:ersin-erdal/kibana into 216308-support-rrule-for-task-scheduling
…:ersin-erdal/kibana into 216308-support-rrule-for-task-scheduling
… src/core/server/integration_tests/ci_checks'
…:ersin-erdal/kibana into 216308-support-rrule-for-task-scheduling
SiddharthMantri
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One nit regarding the authz config for the new route.
| security: { | ||
| authz: { | ||
| enabled: false, | ||
| reason: 'This route is opted out from authorization', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Can this be expanded to better explain the reasoning for opting out?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated in 6030bf0
| next_run: string | undefined; | ||
| notification: RawScheduledReport['notification']; | ||
| schedule: RruleSchedule; | ||
| title: RawScheduledReport['title']; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This title is extracted from the jobParams, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it currently is but we could also make it an explicit field set in the schedule API if that is preferable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh no worries, I receive the title from the sharing data before creating the jobParams string so no need to specify it separately 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
I tried out Verify steps with user1 and user2 and everything worked as expected. However, when I use a job id from user2 while logged in with user1 and do a bulk disable, I get the following: {
"scheduled_report_ids": [],
"errors": [
{
"message": "Insufficient privileges to disable scheduled report \"c348b993-d106-482f-b538-3c9aee190a9f\".",
"status": 403,
"id": "c348b993-d106-482f-b538-3c9aee190a9f"
}
],
"total": 1
}I'm wondering if we should return a 404 instead? If we go that route, perhaps we can log the message we're currently generating as a WARN, since it's obviously useful info ... |
Updated in 6030bf0 |
pmuellr
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, left some comments
|
|
||
| export function scheduledQueryFactory(reportingCore: ReportingCore): ScheduledQueryFactory { | ||
| return { | ||
| async list(req, res, user, page = 1, size = DEFAULT_SCHEDULED_REPORT_LIST_SIZE) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feels like we should put each route in a separate file, but perhaps we can plan on doing that when we add the next set of APIs (enable?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good. I was following what already existed for the jobs APIs but I guess we can start doing things the way we're used to in response ops now :)
| }); | ||
| } else { | ||
| // check if user is allowed to update this scheduled report | ||
| if (so.attributes.createdBy !== username && !canManageReporting) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if username is false, presumably we'd always go through this if block, maybe we could exit early instead?
| // check if user is allowed to update this scheduled report | ||
| if (so.attributes.createdBy !== username && !canManageReporting) { | ||
| bulkErrors.push({ | ||
| message: `Insufficient privileges to disable scheduled report "${so.id}".`, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the intention with a 404 is to not leak the existance of resources the client doesn't have access to. So the message should probably be "not found". Having the logged warn is good though, since it's ok to "leak" that info in the logs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it considered a leak though? If we try to access a saved object that doesn't exist, we get a Saved object not found error that returns ${type}/${id} in the message. This only returns the ID that we're trying to disable, not any additional information about it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I understand what you're saying...I'll update the message to be a generic not found.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated in fbac095
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ya, I think my general experience with things is when you don't have access (haven't logged in), results tend to look like "I can't find that" - but not sure if we have guidelines about things like that ...
| page, | ||
| perPage: size, | ||
| ...(!canManageReporting | ||
| ? { filter: `scheduled_report.attributes.createdBy: "${username}"` } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
username can be false, at least type-wise, so in such cases (API keys?), this would search for reports by false.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch! We actually prevent scheduling reports if security is disabled and api keys are not available because we need that API key for scheduled reports. I probably carried over that typing from the normal reports so I'll fix the typing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed the types, added a double check that username is specified and added a functional test to ensure we're getting an error when scheduling reports with security disabled: 1f6abbb
💚 Build Succeeded
Metrics [docs]Public APIs missing comments
Async chunks
Page load bundle
Unknown metric groupsAPI count
ESLint disabled line counts
References to deprecated APIs
Total ESLint disabled count
History
cc @ymao1 |
Resolves #216313 ## Summary This is a feature branch that contains the following commits. Each individual linked PR contains a summary and verification instructions. * Schedule API - #219771 * Scheduled report task runner - #219770 * List and disable API - #220922 * Audit logging - #221846 * Send scheduled report emails - #220539 * Commit to check license - f5f9d9d * Update to list API response format - #224262 --------- Co-authored-by: Ersin Erdal <[email protected]> Co-authored-by: kibanamachine <[email protected]> Co-authored-by: Ersin Erdal <[email protected]> Co-authored-by: Elastic Machine <[email protected]> Co-authored-by: Alexi Doak <[email protected]>
Resolves elastic#216313 ## Summary This is a feature branch that contains the following commits. Each individual linked PR contains a summary and verification instructions. * Schedule API - elastic#219771 * Scheduled report task runner - elastic#219770 * List and disable API - elastic#220922 * Audit logging - elastic#221846 * Send scheduled report emails - elastic#220539 * Commit to check license - elastic@f5f9d9d * Update to list API response format - elastic#224262 --------- Co-authored-by: Ersin Erdal <[email protected]> Co-authored-by: kibanamachine <[email protected]> Co-authored-by: Ersin Erdal <[email protected]> Co-authored-by: Elastic Machine <[email protected]> Co-authored-by: Alexi Doak <[email protected]> (cherry picked from commit a409627) # Conflicts: # src/platform/packages/private/kbn-reporting/common/routes.ts # x-pack/platform/plugins/private/canvas/server/feature.test.ts # x-pack/platform/plugins/private/reporting/server/core.ts # x-pack/platform/plugins/private/reporting/server/features.ts # x-pack/platform/plugins/shared/features/server/__snapshots__/oss_features.test.ts.snap # x-pack/platform/test/api_integration/apis/features/features/features.ts # x-pack/test_serverless/api_integration/test_suites/chat/platform_security/authorization.ts # x-pack/test_serverless/api_integration/test_suites/observability/platform_security/authorization.ts # x-pack/test_serverless/api_integration/test_suites/search/platform_security/authorization.ts # x-pack/test_serverless/api_integration/test_suites/security/platform_security/authorization.ts

Towards #216313
Note
This PR will be merged into a feature branch
Summary
Adds internal APIs for listing and disabling scheduled reports. For this initial iteration, we are not adding an
enableAPI.This adds a
Manage Scheduled Reportsfeature privilege that, if the user has it, allows them to view and disable the scheduled reports of any user in the current space.To Verify
user1) with the ability to generate reports but not manage reports. Use the schedule API to schedule some reports as this user.user2) with the ability to manage reports. Use the schedule API to schedule some reports as this user.user1, use the Dev Console to list scheduled reports. You should only see those created byuser1.user1should also be able to disable their own reports.user2, use the Dev Console to list scheduled reports. You should see reports from bothuser1anduser2.user2should be able to disable a report created byuser1.